Increasingly, computer systems have needed to protect themselves against unwanted code and related attacks. Such unwanted code has generally taken the form of viruses, worms, Trojan horses, spyware, adware, and so forth. Such unwanted code is often injected by an person that intrudes upon a target network. The damage and/or inconvenience capable of being incurred by these types of unwanted code/attacks has ranged from mild interference with a program, such as the display of an unwanted political message in a dialog box, to the complete destruction of contents on a hard drive, and even the theft of personal information.
Various systems have been developed for combating such unwanted code/attacks. One example includes intrusion prevention systems (IPSs). In use, an IPS monitors network traffic and typically has the ability to take immediate action, based on a set of rules established by a user. Often IPSs are equipped with graphical user interfaces for allowing the user to view various potential security events (e.g. alerts, etc.) that are collected from a plurality of sensors dispersed within one or more networks.
Since hundreds of sensors may potentially exist, the aforementioned security events may be received at a very high rate (e.g. up to hundreds of alerts per minute, etc.). Thus, a user may easily be overwhelmed by the volume of security events, making it difficult for him/her to pay attention to a truly severe security breach, etc. In order to address the need of the user to deal with such abundance of information, some IPSs have provided highly flexible view customization/aggregation functions to allow an administrator to group, filter, and sort security events.
Still yet, some IPSs allow a user to configure rules which govern the manner in which security events may be automatically correlated and combined into “incidents.” Such process is called correlation. While such correlation has the potential of significantly improving the effectiveness of the IPS, configuration of the aforementioned rules is difficult. For example, users must often manually enter security event attributes of interest into the IPS for generation of a desired rule that is capable of filtering security events with such attribute.
There is thus a need for overcoming these and/or other problems associated with the prior art.